In recent years, flexibility has emerged as a divisive issue in discussions about the appropriate design of processes for making software. Partisans in both research and practice argue for and against plan-based (allegedly inflexible) and agile (allegedly too flexible) approaches. The stakes in this debate are high; questions raised about plan-based approaches undermine longstanding claims that those approaches, when realized, represent maturity of practice. In this commentary, we call for research programs that will move beyond partisan disagreement to a more nuanced discussion, one that takes into account both benefits and costs of flexibility Key to such programs will be the development of a robust contingency framework for deciding when (in what conditions) plan-based and agile methods should be used. We develop a basic contingency framework in this paper, one that models the benefit/cost economics described in narratives about the transition from craft to industrial production of physical products. We use this framework to demonstrate the power of even a simple model to help us accomplish three objectives: (1) to refocus discussions about the appropriate design of software development processes, concentrating on when to use particular approaches and how they might be usefully combined; (2) to suggest and guide a trajectory of research that can support and enrich this discussion; and (3) to suggest a technology-based explanation for the emergence of agile development at this point in history. Although we are not the first to argue in favor of a contingency perspective, we show that there remain many opportunities for information systems (IS) research to have a major impact on practice in this area.
An agency framework is used to model the behavior of software developers as they weigh concerns about product quality against concerns about missing individual task dead- lines. Developers who care about quality but fear the career impact of missed deadlines may take "shortcuts." Managers sometimes attempt to reduce this risk via their deadline-setting policies; a common method involves adding slack to best estimates when setting deadlines to partially alleviate the time pressures believed to encourage shortcut-taking. This paper derives a formal relationship between deadline-setting policies and software product quality. It shows that: (1) adding slack does not always preserve quality, thus, systematically adding slack is an incomplete policy for minimizing costs; (2) costs can be minimized by adopting policies that permit estimates of completion dates and deadlines that arc different and; (3) contrary to casual intuition, shortcut-taking can be eliminated by setting deadlines aggressively, thereby maintaining or even increasing the time pressures under which developers work.